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Cooperating Layered Architecture for Software-Defined Networking (CLAS) 
Abstract 


Software-Defined Networking (SDN) advocates for the separation of the 
control plane from the data plane in the network nodes and its 
logical centralization on one or a set of control entities. Most of 
the network and/or service intelligence is moved to these control 
entities. Typically, such an entity is seen as a compendium of 
interacting control functions in a vertical, tightly integrated 
fashion. The relocation of the control functions from a number of 
distributed network nodes to a logical central entity conceptually 
places together a number of control capabilities with different 
purposes. As a consequence, the existing solutions do not provide a 
clear separation between transport control and services that rely 
upon transport capabilities. 


This document describes an approach called Cooperating Layered 
Architecture for Software-Defined Networking (CLAS), wherein the 
control functions associated with transport are differentiated from 
those related to services in such a way that they can be provided and 
maintained independently and can follow their own evolution path. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not candidates for any level of Internet Standard; 
see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8597. 


Copyright Notice 


Copyright (c) 2019 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


Network softwarization advances are facilitating the introduction of 
programmability in the services and infrastructures of 

telecommunications operators. This is generally achieved through the 
introduction of Software-Defined Networking (SDN) [RFC7149] [RFC7426] 
capabilities in the network, including controllers and orchestrators. 


However, there are concerns of a different nature that these SDN 
capabilities have to resolve. On the one hand, actions focused on 
programming the network to handle the connectivity or forwarding of 
digital data between distant nodes are needed. On the other hand, 
actions devoted to programming the functions or services that process 
(or manipulate) such digital data are also needed. 


SDN advocates for the separation of the control plane from the data 
plane in the network nodes by introducing abstraction among both 
planes, allowing the control logic on a functional entity, which is 
commonly referred as SDN Controller, to be centralized; one or 
multiple controllers may be deployed. A programmatic interface is 
then defined between a forwarding entity (at the network node) and a 
control entity. Through that interface, a control entity instructs 
the nodes involved in the forwarding plane and modifies their 
traffic-forwarding behavior accordingly. Support for additional 
capabilities (e.g., performance monitoring, fault management, etc.) 
could be expected through this kind of programmatic interface 
RFC7149]. 


Most of the intelligence is moved to this kind of functional entity. 
Typically, such an entity is seen as a compendium of interacting 
control functions in a vertical, tightly integrated fashion. 


The approach of considering an omnipotent control entity governing 
the overall aspects of a network, especially both the transport 
network and the services to be supported on top of it, presents a 
number of issues: 


o From a provider perspective, where different departments usually 
are responsible for handling service and connectivity (i.e., 
transport capabilities for the service on top), the mentioned 
approach offers unclear responsibilities for complete service 
provision and delivery. 


o Complex reuse of functions for the provision of services. 


o Closed, monolithic control architectures. 
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o Difficult interoperability and interchangeability of functional 
components. 


o Blurred business boundaries among providers, especially in 
situations where one provider provides only connectivity while 
another provider offers a more sophisticated service on top of 
that connectivity. 


o Complex service/network diagnosis and troubleshooting, 
particularly to determine which layer is responsible for a 
failure. 


The relocation of the control functions from a number of distributed 
network nodes to another entity conceptually places together a number 
of control capabilities with different purposes. As a consequence, 
the existing SDN solutions do not provide a clear separation between 
Services and transport control. Here, the separation between service 
and transport follows the distinction provided by [Y.2011] and as 
defined in Section 2 of this document. 


This document describes an approach called Cooperating Layered 
Architecture for SDN (CLAS), wherein the control functions associated 
with transport are differentiated from those related to services in 
such a way that they can be provided and maintained independently and 
can follow their own evolution path. 


Despite such differentiation, close cooperation between the servic 
and transport layers (or strata in [Y.2011]) and the associated 
components are necessary to provide efficient usage of the resources. 


2. Terminology 
This document makes use of the following terms: 
o Transport: denotes the transfer capabilities offered by a 


networking infrastructure. The transfer capabilities can rely 
upon pure IP techniques or other means, such as MPLS or optics. 


O Service: denotes a logical construct that makes use of transport 
capabilities. 


This document does not make any assumptions about the functional 
perimeter of a service that can be built above a transport 
infrastructure. As such, a service can be offered to customers or 
invoked for the delivery of another (added-value) service. 
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o Layer: refers to the set of elements that enable either transport 
or service capabilities, as defined previously. In [Y.2011], this 
is referred to as a "Stratum", and the two terms are used 
interchangeably. 


o Domain: is a set of elements that share a common property or 
characteristic. In this document, it applies to the 
administrative domain (i.e., elements pertaining to the same 
organization), technological domain (elements implementing the 
same kind of technology, such as optical nodes), etc. 


o SDN Intelligence: refers to the decision-making process that is 
hosted by a node or a set of nodes. These nodes are called SDN 
controllers. 


The intelligence can be centralized or distributed. Both schemes 
are within the scope of this document. 


An SDN Intelligence relies on inputs from various functional 
blocks, such as: network topology discovery, service topology 
discovery, resource allocation, business guidelines, customer 
profiles, service profiles, etc. 


The exact decomposition of an SDN Intelligence, apart from the 
layering discussed here, is out of the scope of this document. 


Additionally, the following acronyms are used in this document: 
CLAS: Cooperating Layered Architecture for SDN 
FCAPS: Fault, Configuration, Accounting, Performance, and Security 


SDN: Software-Defined Networking 


SLA: Service Level Agreement 


Architecture Overview 


Current operator networks support multiple services (e.g., Voice over 
IP (VoIP), IPTV, mobile VoIP, critical mission applications, etc.) on 
a variety of transport technologies. The provision and delivery of a 
service independent of the underlying transport capabilities require 
a separation of the service-related functionalities and an 
abstraction of the transport network to hide the specifics of the 
underlying transfer techniques while offering a common set of 
capabilities. 
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Such separation can provide configuration flexibility and 
adaptability from the point of view of either the services or the 
transport network. Multiple services can be provided on top of a 
common transport infrastructure; similarly, different technologies 
can accommodate the connectivity requirements of a certain service. 
Close coordination among these elements is required for consistent 
service delivery (inter-layer cooperation). 


This document focuses particularly on the means to: 

o expose transport capabilities to services. 

O capture transport requirements of services. 

o notify service intelligence of underlying transport events, for 


example, to adjust a service decision-making process with 
underlying transport events. 


o instruct the underlying transport capabilities to accommodate new 
requirements, etc. 


An example is guaranteeing some Quality-of-Service (QoS) levels. 
Different QoS-based offerings could be present at both the service 
and transport layers. Vertical mechanisms for linking both service 
and transport QoS mechanisms should be in place to provide quality 
guarantees to the end user. 


CLAS architecture assumes that the logically centralized control 
functions are separated into two functional layers. One of the 
functional layers comprises the service-related functions, whereas 
the other one contains the transport-related functions. The 
cooperation between the two layers is expected to be implemented 
through standard interfaces. 


Figure 1 shows the CLAS architecture. It is based on functional 
Separation in the Next Generation Network (NGN) architecture defined 
by the ITU-T in [Y.2011], where two strata of functionality are 
defined. These strata are the Service Stratum, comprising the 
service-related functions, and the Transport Stratum, covering the 


transport-related functions. The functions of each of these layers 
are further grouped into the control, management, and user (or data) 
planes. 


CLAS adopts the same structured model described in [Y.2011] but 
applies it to the objectives of programmability through SDN 


[RFC7149]. In this respect, CLAS advocates for addressing services 
and transport in a separated manner because of their differentiated 
concerns. 
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3. 


In the CLAS architecture, both the control and management functions 
are considered to be performed by one or a set of SDN controllers 
(due to, for example, scalability, reliability), providing the SDN 
Intelligence in such a way that separated SDN controllers are present 
in the Service and Transport Strata. Management functions are 
considered to be part of the SDN Intelligence to allow for effective 
operation in a service provider ecosystem [RFC7149], although some 
initial propositions did not consider such management as part of the 
SDN environment [ONFArch]. 


Furthermore, the generic user- or data-plane functions included in 
the NGN architecture are referred to here as resource-plan 
functions. The resource plane in each stratum is controlled by the 
corresponding SDN Intelligence through a standard interface. 


The SDN controllers cooperate in the provision and delivery of 

services. There is a hierarchy in which the Service SDN Intelligence 
makes requests of the Transport SDN Intelligence for the provision of 
transport capabilities. 


The Service SDN Intelligence acts as a client of the Transport SDN 
Intelligence. 


Furthermore, the Transport SDN Intelligence interacts with the 
Service SDN Intelligence to inform it about events in the transport 
network that can motivate actions in the service layer. 


Despite not being shown in Figure 1, the resource planes of each 
stratum could be connected. This will depend on the kind of service 
provided. Furthermore, the Service Stratum could offer an interface 
to applications to expose network service capabilities to those 
applications or customers. 


1. Functional Strata 
As aforementioned, there is a functional split that separates 


transport-related functions from service-related functions. Both 
strata cooperate for consistent service delivery. 


Consistency is determined and characterized by the service layer. 


.1.1. Transport Stratum 


The Transport Stratum comprises the functions focused on the transfer 
of data between the communication endpoints (e.g., between end-user 
devices, between two service gateways, etc.). The data-forwarding 
nodes are controlled and managed by the Transport SDN component. 
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The control plane in the SDN Intelligence is in charge of instructing 
the forwarding devices to build the end-to-end data path for each 
communication or to make sure the forwarding service is appropriately 
set up. Forwarding may not be rely solely on the preconfigured 
entries; means can be enabled so that involved nodes can dynamically 
build routing and forwarding paths (this would require that the nodes 
retain some of the control and management capabilities for enabling 
this). Finally, the management plane performs management functions 
(i.e., FCAPS) on those devices, like fault or performance management, 
as part of the Transport Stratum capabilities. 


3.1.2. Service Stratum 


The Service Stratum contains the functions related to the provision 
of services and the capabilities offered to external applications. 
The resource plane consists of the resources involved in the service 
delivery, such as computing resources, registries, databases, etc. 


The control plane is in charge of controlling and configuring those 
resources as well as interacting with the control plane of the 
Transport Stratum in client mode to request transport capabilities 
for a given service. In the same way, the management plane 
implements management actions on the service-related resources and 
interacts with the management plane in the Transport Stratum to 
ensure management cooperation between layers. 


3.1.3. Recursiveness 


Recursive layering can happen in some usage scenarios in which the 
Transport Stratum is itself structured in the Service and Transport 
Strata. This could be the case in the provision of a transport 
service complemented with advanced capabilities in addition to the 
pure data transport (e.g., maintenance of a given SLA [RFC7297]). 


Recursiveness has also been discussed in [ONFArch] as a way of 
reaching scalability and modularity, where each higher level can 
provide greater abstraction capabilities. Additionally, 
recursiveness can allow some multi-domain scenarios where single or 
multiple administrative domains are involved, such as those described 
in Section 6.3. 


3.2. Plane Separation 


The CLAS architecture leverages plane separation. As mentioned in 
Sections 3.1.1 and 3.1.2, three different planes are considered for 
each stratum. The communication among these three planes (with the 
corresponding plane in other strata) is based on open, standard 
interfaces. 
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3.2.1. Control Plane 


The control plane logically centralizes the control functions of each 
stratum and directly controls the corresponding resources. [RFC7426] 
introduces the role of the control plane in an SDN architecture. 

This plane is part of an SDN Intelligence and can interact with other 
control planes in the same or different strata to perform control 
functions. 


3.2.2. Management Plane 


The management plane logically centralizes the management functions 
for each stratum, including the management of the control and 

resource planes. [RFC7426] describes the functions of the management 
plane in an SDN environment. This plane is also part of the SDN 
Intelligence and can interact with the corresponding management 
planes residing in SDN controllers of the same or different strata. 


3.2.3. Resource Plane 


The resource plane comprises the resources for either the transport 
or the service functions. In some cases, the service resources can 
be connected to the transport ones (e.g., being the terminating 
points of a transport function); in other cases, it can be decoupled 
from the transport resources (e.g., one database keeping a register 


for the end user). Both the forwarding and operational planes 
proposed in [RFC7426] would be part of the resource plane in this 
architecture. 

4. Required Features 


Since the CLAS architecture implies the interaction of different 
layers with different purposes and responsibilities, a number of 
features are required to be supported: 


o Abstraction: the mapping of physical resources into the 
corresponding abstracted resources. 


o Service-Parameter Translation: the translation of service 
parameters (e.g., in the form of SLAs) to transport parameters (or 
capabilities) according to different policies. 


o Monitoring: mechanisms (e.g., event notifications) available in 


order to dynamically update the (abstracted) resources' status 
while taking into account, for example, the traffic load. 


Contreras, et al. Informational [Page 11] 


RFC 8597 Layered SDN Architecture May 2019 


55 


o Resource Computation: functions able to decide which resources 
will be used for a given service request. As an example, 
functions like PCE could be used to compute/select/decide a 
certain path. 


o Orchestration: the ability to combine diverse resources (e.g., IT 
and network resources) in an optimal way. 


o Accounting: record of resource usage. 


O Security: secure communication among components, preventing, for 
example, DoS attacks. 


Communication between SDN Controllers 


The SDN controllers residing respectively in the Service and 
Transport Strata need to establish tight coordination. Mechanisms 
for transferring relevant information for each stratum should be 
defined. 


From the service perspective, the Service SDN Intelligence needs to 
easily access transport resources through well-defined APIs to 
retrieve the capabilities offered by the Transport Stratum. There 
could be different ways of obtaining such transport-aware 
information, i.e., by discovering or publishing mechanisms. In the 
former case, the Service SDN Intelligence could be able to handle 
complete information about the transport capabilities (including 
resources) offered by the Transport Stratum. In the latter case, th 
Transport Stratum reveals the available capabilities, for example, 
through a catalog, reducing the amount of detail of the underlying 
network. 


On the other hand, the Transport Stratum must properly capture the 
Service requirements. These can include SLA requirements with 
Specific metrics (such as delay), the level of protection to be 
provided, maximum/minimum capacity, applicable resource constraints, 
etc. 


The communication between controllers must also be secure, e.g., by 
preventing denial of service or any other kind of threat (similarly, 
communications with the network nodes must be secure). 


Deployment Scenarios 


Different situations can be found depending on the characteristics of 
the networks involved in a given deployment. 
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6.1. Full SDN Environments 


This case considers that the networks involved in the provision and 
delivery of a given service have SDN capabilities. 


6.1.1. Multiple Service Strata Associated with a Single Transport 
Stratum 


A single Transport Stratum can provide transfer functions to more 
than one Service Stratum. The Transport Stratum offers a standard 
interface(s) to each of the Service Strata. The Service Strata are 
the clients of the Transport Stratum. Some of the capabilities 
offered by the Transport Stratum can be isolation of the transport 
resources (slicing), independent routing, etc. 


6.1.2. Single Service Stratum Associated with Multiple Transport Strata 


A single Service Stratum can make use of different Transport Strata 
for the provision of a certain service. The Service Stratum invokes 
standard interfaces to each of the Transport Strata, and orchestrates 
the provided transfer capabilities for building the end-to-end 
transport needs. 


6.2. Hybrid Environments 


This case considers scenarios where one of the strata is totally or 
partly legacy. 


6.2.1. SDN Service Stratum Associated with a Legacy Transport Stratum 


An SDN service Stratum can interact with a legacy Transport Stratum 
through an interworking function that is able to adapt SDN-based 
control and management service-related commands to legacy transport- 
related protocols, as expected by the legacy Transport Stratum. 


The SDN Intelligence in the Service Stratum is not aware of the 
legacy nature of the underlying Transport Stratum. 


6.2.2. Legacy Service Stratum Associated with an SDN Transport Stratum 


A legacy Service Stratum can work with an SDN-enabled Transport 
Stratum through the mediation of an interworking function capable of 
interpreting commands from the legacy service functions and 
translating them into SDN protocols for operation with the SDN- 
enabled Transport Stratum. 
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6.3. Multi-domain Scenarios in the Transport Stratum 


The Transport Stratum can be composed of transport resources that are 
part of different administrative, topological, or technological 
domains. The Service Stratum can interact with a single entity in 
the Transport Stratum in case some abstraction capabilities are 
provided in the transport part to emulate a single stratum. 


Those abstraction capabilities constitute a service itself offered by 
the Transport Stratum to the services making use of this stratum. 
This service is focused on the provision of transport capabilities, 
which is different from the final communication service using such 
capabilities. 


In this particular case, this recursion allows multi-domain scenarios 
at the transport level. 


Multi-domain situations can happen in both single-operator and multi- 
operator scenarios. 


In single-operator scenarios, a multi-domain or end-to-end 
abstraction component can provide a homogeneous abstract view of the 
underlying heterogeneous transport capabilities for all the domains. 


Multi-operator scenarios at the Transport Stratum should support the 
establishment of end-to-end paths in a programmatic manner across the 
involved networks. For example, this could be accomplished by each 
of the administrative domains exchanging their traffic-engineered 
information [RFC7926]. 


7. Use Cases 


This section presents a number of use cases as examples of the 
applicability of the CLAS approach. 


7.1. Network Function Virtualization (NFV) 


NFV environments offer two possible levels of SDN control 
[GSNFV-EVE005]. One level is the need to control the NFV 
Infrastructure (NFVI) to provide end-to-end connectivity among VNFs 
(Virtual Network Functions) or among VNFs and PNFs (Physical Network 
Functions). A second level is the control and configuration of the 
VNFs themselves (in other words, the configuration of the network 
service implemented by those VNFs), which benefits from the 
programmability brought by SDN. The two control concerns are 
Separate in nature. However, interaction between the two can be 
expected in order to optimize, scale, or influence one another. 
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7.2. Abstraction and Control of TE Networks 


Abstraction and Control of TE Networks (ACTIN) [RFC8453] presents a 
framework that allows the creation of virtual networks to be offered 
to customers. The concept of "provider" in ACTIN is limited to the 
offering of virtual network services. These services are essentially 
transport services and would correspond to the Transport Stratum in 
CLAS. On the other hand, the Service Stratum in CLAS can be 
assimilated as a customer in the context of ACTIN. 


ACTN defines a hierarchy of controllers to facilitate the creation 
and operation of the virtual networks. An interface is defined for 
the relationship between the customers requesting these virtual 
network services and the controller in charge of orchestrating and 
Serving such a request. Such an interface is equivalent to the one 
defined in Figure 1 (Section 3) between the Service and Transport 
Strata. 


8. Challenges for Implementing Actions between Service and Transport 
Strata 


The distinction of service and transport concerns raises a number of 
challenges in the communication between the two strata. The 
following list reflects some of the identified challenges: 


o Standard mechanisms for interaction between layers: Nowadays, 
there are a number of proposals that could accommodate requests 
from the Service Stratum to the Transport Stratum. 


Some of the proposals could be solutions like the Connectivity 
Provisioning Negotiation Protocol [CPNP] or the Intermediate- 
Controller Plane Interface (I-CPI) [ONFArch]. 


Other potential candidates could be the Transport API [TAPI] or 
the Transport Northbound Interface [TRANS-NORTH]. Each of these 
options has a different scope. 


o Multi-provider awareness: In multi-domain scenarios involving more 
than one provider at the transport level, the Service Stratum may 
or may not be aware of such multiplicity of domains. 


If the Service Stratum is unaware of the multi-domain situation, 
then the Transport Stratum acting as the entry point of the 
Service Stratum request should be responsible for managing the 
multi-domain issue. 
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On the contrary, if the Service Stratum is aware of the multi- 
domain situation, it should be in charge of orchestrating the 
requests to the different underlying Transport Strata to compose 


the final end-to-end path among service endpoints (i.e., service 
functions). 
O SLA mapping: Both strata will handle SLAs, but the nature of those 


SLAs could differ. Therefore, it is required for the entities in 
each stratum to map service SLAs to connectivity SLAs in order to 
nsure proper service delivery. 


O Association between strata: The association between strata could 
be configured beforehand, or both strata could require the use of 
a discovery mechanism that dynamically establishes the association 
between the strata. 


o Security: As reflected before, the communication between strata 
must be secure to prevent attacks and threats. Additionally, 
privacy should be enforced, especially when addressing multi- 
provider scenarios at the transport level. 


o Accounting: The control and accountancy of resources used and 
consumed by services should be supported in the communication 
among strata. 


IANA Considerations 
This document has no IANA actions. 

Security Considerations 
The CLAS architecture relies upon the functional entities that are 
introduced in [RFC7149] and [RFC7426]. As such, security 


considerations discussed in Section 5 of [RFC7149], in particular, 
must be taken into account. 


The communication between the service and transport SDN controllers 
must rely on secure means that achieve the following: 


o Mutual authentication must b nabled before taking any action. 
o Message integrity protection. 


Each of the controllers must be provided with instructions regarding 
the set of information (and granularity) that can be disclosed to a 
peer controller. Means to prevent the leaking of privacy data (e.g., 
from the Service Stratum to the Transport Stratum) must be enabled. 
The exact set of information to be shared is deployment specific. 
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A corrupted controller may induce some disruption on another 


controller. 


Protection against such attacks should be enabled. 


Security in the communication between the strata described here 


should apply to the APIs (and/or protocols) to be defined among them. 
Consequently, security concerns will correspond to the specific 
solution. 
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Appendix A. Relationship with RFC 7426 


[RFC7426] introduces an SDN taxonomy by defining a number of planes, 
abstraction layers, and interfaces or APIs among them as a means of 
clarifying how the different parts constituent of SDN (network 
devices, control and management) relate. A number of planes are 
defined, including: 


o Forwarding Plane: focused on delivering packets in the data path 
based on the instructions received from the control plane. 


o Operational Plane: centered on managing the operational state of 
the network device. 


o Control Plane: dedicated to instructing the device on how packets 
should be forwarded. 


o Management Plane: in charge of monitoring and maintaining network 
devices. 


o Application Plane: enabling the usage for different purposes (as 
determined by each application) of all the devices controlled in 
this manner. 


Apart from these, [RFC7426] proposes a number of abstraction layers 
that permit the integration of the different planes through common 
interfaces. CLAS focuses on control, management, and resource planes 
as the basic pieces of its architecture. Essentially, the control 
plane modifies the behavior and actions of the controlled resources. 
The management plane monitors and retrieves the status of those 
resources. And finally, the resource plane groups all the resources 
related to the concerns of each stratum. 


From this point of view, CLAS planes can be seen as a superset of 
those defined in [RFC7426]. However, in some cases, not all the 
planes considered in [RFC7426] may be totally present in CLAS 
representation (e.g., the forwarding plane in the Service Stratum). 


That being said, the internal structure of CLAS strata could follow 
the taxonomy defined in [RFC7426]. What is different is the 
specialization of the SDN environments through the distinction 
between service and transport. 
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